The invention relates generally to computer systems and deals more particularly with allocation of address spaces within a storage.
An application program executing in a computer system often makes requests to access storage, for example to read or write data. The request usually includes a specific address. In response, the operating system must determine a suitable location to which to write or the precise location of the data to be read. There are several aspects to this determination. First, the address provided in the request may have fewer or more bits than required to uniquely identify any one location in storage. In the former case, the operating system may need to select or identify a smaller address space or region within the storage having a size which corresponds to the number of bits in the address provided by the request. Such an address space can be used to store related data required by the application which made the request. Other address spaces can be selected for other applications and, in such a case, identical addresses specified by two applications may correspond to different storage locations. Second, an address space may be dedicated to one application or shared between two or more applications. Third, in a computer system having more than one logical operating system, more than one of the operating systems may need to control the location of the address space allocated for an application program.
A previously known IBM ES/9000 computer system can execute an IBM VM/ESA (R) operating system which includes a hypervisor or host program. The host creates a multiplicity of virtual machines which each comprise a separate guest operating system. Each guest appears to the user as a separate computer and executes application programs that require storage. Each guest controls which address space or spaces its applications can access and provides a corresponding access list entry token (ALET) to the application upon request. The application returns the ALET with a subsequent storage access request and the machine translates the ALET by access register translation ("ART") into a segment table designation (STD) using tables defined by the guest. The STD corresponds to the address space in which the referenced address resides. Then, the machine, according to guest-defined tables, performs dynamic address translation ("DAT") using the STD and operand address as inputs to yield a guest real address. Then, the machine performs prefixing on the guest real address to yield a guest absolute address. The "guest absolute address" is the address determined after final translation by the guest. ART and DAT in a guest operating system are described in a publication entitled "ESA/390 Interpretive-Execution Architecture, Foundation for VM/ESA" by D. L. Osisek et al. in IBM Systems Journal, Volume 39, No. 1, pages 34-51 (1991). Also, a publication entitled "ESA/390 Principles of Operation" which is available from International Business Machines Corporation at Mechanicsburg, Pa. by order #SA22-7201 describes prefixing, ART and DAT in detail but not in a guest operating system. ART in a non-guest operating system is also described in U.S. Pat. No. 4,979,098 and a publication entitled "Concepts of Enterprise Systems Architecture/370" by K. E. Plambeck in IBM Systems Journal volume 28, No. 1 pages 39-61 (1989).
Next, the machine, according to host specification of the guest type, performs "virtual=real or absolute" ("V=R"), "virtual=fixed" ("V=F") or "virtual=virtual" ("V=V") address translation, where "V" on the left side of each equation refers to the guest absolute address resulting from the guest DAT and prefixing. For V=R translation, the host assigns the guest absolute addresses to the lowest address range of the storage. For V=F translation, the host assigns the guest absolute addresses to an address space beginning at a predetermined and constant offset. For V=V translation, the host assigns the guest absolute addresses to a variable address space and can page-out the stored data to auxiliary storage such as external DASD when not in use. (When needed, the host pages-in the stored data.)
U.S. Pat. Nos. 4,456,954 and 4,695,950, a publication entitled "System/370 Extended Architecture: Facilities for Virtual Machines" by P. H. Gum published in IBM Journal Research and Development, Volume 27, No. 6, pages 530-543 (1983), a publication entitled "IBM System/370 Extended Architecture Interpretive Execution" which is available from International Business Machines Corporation at Mechanicsburg, Pa. by order number SA22-7095, and a publication entitled "Multiple Operating Systems On One Processor Complex" by T. L. Borden et al., published in IBM Systems Journal, Volume 28, No. 1, pages 104-123 (1989), teach the implementation of a hypervisor and supporting hardware which allow the DAT and ART processes to proceed at guest level within guest absolute storage. The guest absolute storage is defined by the host program as either a fixed region of host absolute storage (V=R, V=F) or a host-managed virtual address space (V=V). This allows a guest program to create its own address spaces, which may then be shared among applications executing under the same guest, just as they could be if the guest program were executing directly on the processor complex. Note that each guest's access is limited to one host virtual address space, which contains all guest absolute storage. No access to other host spaces is possible.
U.S. Pat. No. 5,230,069 and the publication entitled "ESA/390 Interpretive-Execution Architecture, Foundation for VM/ESA" published in IBM Systems Journal Volume 30, No. 1 (1991) disclose another type of guest called "MCDS". An MCDS guest is a V=V guest for which no ART or DAT translations are permitted at guest level; however, ALETs may be used by guest programs. The ALETs are translated at host level (i.e., through host address translation structures) to select a host address space, which is then input to host DAT. This allows the V=V guest programs to access multiple dedicated and shared host address spaces, subject to authorization controls established by the host. However, such a guest must sacrifice the guest-level address translation. Consequently, full function guest operating systems such as MVS/ESA and VSE/ESA which depend on the translation and related capabilities cannot take advantage of MCDS function. Also, there is no means for the guest operating system to restrict access to the available host spaces to a subset of the applications running under the guest because the application may use any ALET of its choice without intervention from the guest operating system. Also, the additional spaces accessible under MCDS may contain data only; they cannot be a source for execution of program instructions. Finally, the MCDS prior art does not support V=R or V=F guests, and consequently, the V=R and V=F guests cannot access dedicated or shared host-virtual address spaces.
Accordingly, an object of the present invention is to provide an address space allocation process within a virtual machine environment which permits more than one guest/virtual machine to share a single address space and each central access by its applications to the shared address space.
Another object of the present invention is to provide a virtual machine computer system which permits applications executing under a single guest to readily access both guest-managed and host-managed address spaces.
Another object of the present invention is to provide a virtual machine computer system which permits V=R and V=F guests to share an address space.
Another object of the present invention is to allow a guest to use multiple host-managed address spaces as a source for instructions as well as data.